OCR Enabled Management of Accounts Payable and/or Accounts Receivable Auditing Data

ABSTRACT

A number of different tags are input in a fax cover sheet that tell an OCR system not only the identity of the supplier, but also to which client the document should be routed. The OCR system identifies a number of these tags and compares them to stored supplier data to validate to which supplier the document belongs. If the system cannot validate the document, it is routed to a GUI for manual sorting. If there is no coversheet, the system relies upon the OCR system to locate keywords on the document and caller ID information to suggest a correct supplier. The OCR system also clips a separate, horizontal slice of the document (&#39;snippet) that corresponds to the display of any line item and places it in a data base for future reference and reporting. The application collects and associates all corresponding snippets to their originating line items.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 10/349,727, filed Jan. 22, 2003, which application claimspriority to U.S. provisional patent application Ser. No. 60/350,543,filed Jan. 22, 2002, each of which is incorporated herein in itsentirety by this reference thereto.

BACKGROUND OF THE INVENTION

1. Technical Field

The invention relates to managing accounts payable and/or accountsreceivable auditing data. More particularly, the invention relates toOCR enabled management of accounts payable and/or accounts receivableauditing data.

2. Description of the Background Art

The practice of performing recovery audits originated in the early1970's, during a time of increased commerce for the retail industry. Agrowing network of national chain stores led to a rise in competitionfor retail shelf space from different suppliers. Large companies had adifficult time keeping track of the many different vendor price points,rebates, and other various discounts.

Keeping track of such details was not an integral part of purchasingdepartments. Such oversights led to a substantial amount of lost revenuegoing unnoticed in the form of duplicate payments, overpayments, missedshipments, unused credits, and other transactional errors between acompany and its suppliers.

Accounts Payable Audit

Today, in a typical accounts payable (NP) audit, auditors work with theNP records of a company in an attempt to find potentially profitablediscrepancies in a vendor transaction file for the company or individualbusiness units of the company. Although much of an A/P audit can beperformed at a third party location, the NP audit generally requires thecooperation and time of individuals within the client-organization towork in conjunction with the auditors. The A/P audit is a useful toolbut can be time consuming for the client, However, typical A/P auditingfirms are unable to do a thorough job of reviewing vendor data.

Statement Audit

Another type of audit emerging within the auditing industry is astatement audit (SA). An SA is initiated from the vendors' records and,thus, requires little, if any, intrusion within the client-company. Oncevendor files are secured, the auditing company begins the process ofsearching for gaps, differences, and discrepancies that result in theclient-company losing revenue.

An SA deals directly with suppliers and vendors. However, if performedproperly, an SA yields findings that an NP audit could miss. Because ofthe unique nature of an SA, the SA can either stand alone or functionalongside typical NP recovery efforts.

An SA is very labor intensive because the SA audit requires therequesting, receiving, organizing, and following up with vendors onauditing data from many sources. In some statement audits, the number ofsources ranges in the tens of thousands of sources. Due to the laborintensive demands of an SA, very few NP auditing firms in the NPauditing industry, if any, have the capability of doing a thorough andcomplete job for their clients.

Prior art statement audits fail to manage credits based on line itemdata or on a line item basis. Instead, prior art statement auditsattempt to manage credits based only on statement level data, which isnot as detailed as line item data. Prior art statement audits typicallyonly deal with open line items. Prior art statement audits put each openline item in a file and then record a note for each open line itemindicating that the open line item should be checked at some point inthe future. In addition, prior art statement audits only keep track ofclaims. Prior art statement audits fail to keep track of every line itemof a client, e.g. both Debits and Credits.

Transactional Errors

There is no accepted way to predict the success of an audit. However, ageneral rule of thumb is that transactional errors occur with afrequency of about 1/10 of 1%. That translates to a million dollars ofannual recovery for every billion dollars of a company's annual revenue.

The A/P auditing industry is growing in size and stature as third partyNP auditing firms attempt to recover lost profits for their clients.However, since NP auditing firms are unable to do a thorough job ofreviewing vendor data, clients have employed internal auditors in orderto recover lost profits via a statement audit. However, clientstypically are unable to perform statement audits because they do nothave the amount of staff necessary to perform a statement audit.Therefore, a method and system of managing accounts payable auditingdata is needed.

Managing Accounts Payable Auditing Data

U.S. patent application Ser. No. 10/349,727, filed Jan. 22, 2003, andincorporated herein in its entirety by this reference thereto, disclosesa method and system of managing accounts payable auditing data, wherethe auditing data includes at least one line item and is ordered by apropensity to yield claims. The method and system, in an exemplaryembodiment, includes (1) displaying at least one aged line item, (2)identifying credit data among the at least one displayed aged line item,and (3) recording the identified credit data. In an exemplaryembodiment, the aged line item is a line item that has aged for Nmonths, where N is positive integer. In an exemplary embodiment, N is 4.

The displaying includes (a) prompting if there are any line items thatare aged line items that have to be validated and deducted, (b)displaying the number of vendors, by rank, that have and have notresponded and a status assigned to those vendors, and (c) allowing forthe noting and aging for follow up of when the vendor promises a fax, acallback, a mailing of an item, or a check request and when a clientputs a claim on hold.

The recording includes (a) allowing for the entry of contact data for atleast one vendor, (b) allowing for entry of information about a vendorstatement associated with the vendor, (c) allowing for selection ofinformation about credits/claims, credits, or claims of the vendor, (d)allowing for the interaction with the information about thecredits/claims, the credits, or the clams of the vendor, and (e)allowing for the entry of comments about the recording.

The statement recovery auditing disclosed in U.S. patent applicationSer. No. 10/349,727 is based on a process of collecting a high volume ofdata that is located on hard copy documentation. This documentationresides in the accounting records of various audit system suppliers oraudit system clients' customers. For purposes of simplification ofexplanation, but not of limitation, the discussion herein focuses on howthe process works, for any one client and any one supplier.

Collecting this documentation poses a number of challenges. For example,it is preferred to get fresh documentation from each supplier at leastfour times a year. If the client has 15,000 suppliers, then it isnecessary to request, receive, and review as many as 60,000 documents.In addition to the large amount of documentation involved, alsochallenging is the fact that each supplier may have different formats inwhich they deliver the information. Lastly, the suppliers typically donot have any electronic medium for providing the documentation and theytherefore prefer to mail or fax the documentation in hard copy.

To address these issues, it would be advantageous to provide anapplication that not only manages tens of thousands of outreaches tosuppliers, but that also can receive and perform an initial review ofthe responses.

SUMMARY OF THE INVENTION

An embodiment of the invention provides an application that not onlymanages tens of thousands of outreaches to suppliers, but that also canreceive and perform an initial review of the responses. In oneembodiment, an OCR system is used to receive a document and route itthrough the system. In most cases, a faxing agency is provided with acover sheet to use when sending information to the system. A number ofdifferent tags are input in the cover sheet that tell the system notonly the identity of the supplier, but also to which client the documentshould be routed. Some of the tags used are provided by the customer,such as a “Supplier Number” and “Supplier Name,” while others are systemgenerated, i.e. a “Universal ID.” There are also tags that are collectedthat are actual document meta data elements including, but not limitedto, number of pages, received date, and Caller ID of the fax sender. Inany case, the OCR system is used to identify a number of these tags andcompare them to stored supplier data within the system to validate towhich supplier the document belongs. If the system cannot be 100% surewhere the document goes, the document is turned over to a GUI formanually sorting. If there is no coversheet, the system relies upon theOCR system to locate keywords on the document and caller ID informationto suggest a correct supplier.

Additionally, the OCR system also clips a separate small horizontalslice of the document that corresponds to the display of any line item,including both Credits and Debits, and places it in a data base forfuture reference and reporting. This clip is referred to as a snippetBecause each targeted line item identified receives a unique identifierit is possible for the application to collect and associate allcorresponding snippets to their originating line items.

Line items are then sent to the GUI supported by link to the originatingdocument and links to the corresponding snippet. Also of these lineitems can be graphically flagged or highlighted.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram showing the use of an OCR system to receive adocument and route it through the system according to the invention;

FIG. 2 is a flow diagram showing the use of cover sheets that have areasto input data by hand according to the invention;

FIG. 3 is a flow diagram showing the use of OCR functionality wheredocuments are examined and relevant data is placed into variousdatabases according to the invention;

FIG. 4 is a flow diagram showing an embodiment in which verificationdocuments are processed by the OCR system;

FIG. 5 is a flow diagram showing delivery of data from the database withthe corresponding snippets and links to one or more reporting interfacesaccording to the invention;

FIG. 6 is a screen display showing an example of a report according tothe invention; and

FIG. 7 is a block schematic diagram of a machine in the exemplary formof a computer system within which a set of instructions for causing themachine to perform any one of the foregoing embodiment of the inventionmay be executed.

DETAILED DESCRIPTION OF THE INVENTION

An embodiment of the invention provides an application that not onlymanages tens of thousands of outreaches to suppliers, but that also canreceive and perform an initial review of the responses. In a presentlypreferred embodiment, this solution makes use of an Optical CharacterRecognition (OCR) system. The following discussion provides a briefsummary of the basic functions and functionality that an exemplary OCRsystem performs. Each process is described in connection with acorresponding flow chart of FIG. 1-5. Also, it is important tounderstand that different OCR techniques are used at different timesthroughout the process. Many of the OCR tasks are performedsimultaneously, and some are performed independently. It should beappreciated that some of these processes can be performed sequentially,and some are performed on-demand.

A presently preferred embodiment of the invention is employed inconjunction with a computer-implemented method and system that comprisesthe steps of managing, for example, accounts payable data of a clientand/or AR data of a Supplier. In the case of accounts payable data, suchdata can include at least one line item; displaying an aged line itemfrom among the at least one line item, wherein the at least one lineitem relates to a request from a vendor for payment on an account forthe client; identifying credit data among the at least one displayedaged line item, wherein the credit data relates to a deduction that theclient can take against the requested payment; and recording theidentified credit data, wherein one or more of the managing, displaying,identifying and recording steps are implemented by the computer, asdisclosed in U.S. patent application, Ser. No. 10/349,727, filed Jan.22, 2003, and incorporated herein in its entirety by this referencethereto. Those skilled in the art will appreciate that the inventionfinds application with other methods and systems and that the inventionis not limited to this exemplary method and system. For example, but notlimitation, the invention may be applied to managing and reconcilingdebits on the statements as well. Thus, the invention is concerned bothwith collecting and reporting credits that are due to Clients andcollecting and reporting on Debits as well. Accordingly, both AccountsPayable data of the clients and Accounts Receivable data of the Supplierare subject matter for the invention.

Further, a key aspect of the invention is to identify and report ondiscrepancies between the AP records of the Clients and the AR data ofthe Suppliers. In theory the Clients AP and the Suppliers AR recordsshould match but, in practice, they do not. Thus, the invention isapplicable to both sets of data.

FIG. 1 is a flow diagram showing the use of an OCR system (100) toreceive a document and route it through the system. In most cases, afaxing agency is provided with a cover sheet to use when sendinginformation to the system. A number of different tags are input in thecover sheet that tell the system not only the identity of the supplier,but also to which client the document should be routed (102). Some ofthe tags used are provided by the customer, such as a “Supplier Number”and “Supplier Name,” while others are system generated, i.e. a“Universal ID.” In any case, the OCR system is used to identify a numberof these tags and compare them to stored supplier data within the system(104) to validate to which supplier the document belongs (106). If thesystem cannot be 100% sure where the document goes, the document isturned over to a GUI for manually sorting. If there is no coversheet,the system relies upon the OCR system to locate keywords on the documentand caller ID information to suggest a correct supplier.

There are typically two types of coversheets in use: those that arespecifically created and provided to the suppliers for use, i.e.proprietary coversheets, and everything else. If the suppliers use theprovided coversheet, then the system can readily find the necessarytags, etc. Also, there are many times that the supplier's uniquecoversheet is received and then they send the provided coversheet aswell. In this case, all pages of a fax are scanned looking for the tagsthat indicate a provided coversheet is scanned. Even if the providedcoversheet comes as the last page of a 50 page fax, the system stillknows there is a coversheet.

If the supplier does not send the provided coversheet in the fax, thesystem still scans the supplier's coversheet to identify logos orcompany names, and also to match the caller ID of the sender to thesupplier, etc.

FIG. 2 is a flow diagram showing the use of cover sheets that have areasto input data by hand. This embodiment of the invention uses OCRhandwriting recognition to identify this data and store it into adatabase.

Example: Supplier Contact data

When a fax is received, a first consideration in an embodiment of theinvention is the preparation of, and modifications to, such receiveddocuments to bring them into the application. This preparation includes,for example, cleaning the document by de-speckling the images, as wellas removing any vertical lines that show up in faxes. Additionally, thesystem cleans up the text. Further, the system adjusts the alignment androtation of the pages. In a presently preferred embodiment, theseactions are performed for all pages all of the time.

After the fax is received (and prepared as discussed above) (100) thesupplier's identity is established. The OCR system finds the area wherethe Supplier has entered their contact information: name, phone, fax oremail, for example (102). The OCR system recognizes the handwriting(204) and then compares what it sees to what is currently in thedatabase for that supplier. (206) If there is currently no data in thedatabase (208), the OCR enters what it sees and serves it to a user in aGUI to verify the OCR accuracy (212). If there currently is data in thedatabase, the OCR system compares what it is identified from thedocument and decides if the data is the same (208). If it is determinedthat the contact information is the same (210), then the OCR systemnotes the metadata accordingly, e.g. date, time, etc. If the data isdeemed different (208), then the OCR results and the preexisting systemdata are sent to a GUI for human verification (214).

Any of a number of methods can be used to recognize handwriting. Eachmethod cleans the string, then compares the string and, ultimately,rates the string. In one embodiment, the system starts by using theHidden Markov Model (HMM) to determine a Maximum Likelihood Estimation.When this model finishes, it determines that is not likely enough, thenthe system moves onto the next method, such as the Mean Squared ErrorMSE model.

FIG. 3 is a flow diagram showing the use of OCR functionality wheredocuments are examined (100) and relevant data is placed into variousdatabases (302). In this embodiment, data is tagged back to the documentand snippets are created. In this example, a document is received andthe OCR system determines if the there is any data that needs to becollected into the database for review (304). In many cases, the datacollected takes the form of lines of financial data provided in the formof hard copy print outs from financial systems. The OCR systemidentifies any financial tables on the page and automatically reads thecolumn headers and compares them to the headers in a table master. Then,the OCR system scans through the entirety of the document, places allthe targeted line items into the database, and marks them on thedocument within the GUI. The OCR system then tags the location of eachtargeted line back to its original location in the document for fastfuture connectivity and recall (306).

Additionally, the OCR system also clips a separate small horizontalslice of the document that corresponds to the display of any line itemand places it in a data base for future reference and reporting (308).This clip is referred to as a snippet. Because each targeted line itemidentified receives a unique identifier it is possible for theapplication to collect and associate all corresponding snippets to theiroriginating line items.

Snippets can be created for all lines of data at any time. Thus, it ispossible to allow any user, e.g. client, supplier, etc., to createdifferent types of snippets on-demand within the GUI. The snippetsdescribed herein are specific and are generated by JAVA basedprogramming. Snippets are regional, sub images of the original document.Borders are determined by line heights and by location of the blackpixels. This is why the pre-treating and cleaning of faxes is important.The system is able to recognize white space and then continue toconstrict its focus until it identifies a black pixel. Once a blackpixel is identified, the system follows the rules of the JAVA program todetermine what is snippet-ed. It should be appreciated that a snippetcan be vertical in nature as well, and not always horizontal.

Line items are then sent to the GUI (310) supported by link to theoriginating document and links to the corresponding snippet. Also ofthese line items can be graphically flagged or highlighted.

FIG. 4 is a flow diagram showing an embodiment in which verificationdocuments are processed by the OCR system. Many line items requireadditional supporting documentation from the supplier and thus require afollow up contact and request for information. This request isautomatically generated by the system (400) and can ask a number offollow up questions, including a request for a signature. The documentthat is sent out for this purpose is not only a form, but it is alsointended to be used as a cover sheet. It can contain many of the sametags, as well as additional tags as discussed in FIG. 1. The documentmay contain a series of questions for the entity that correspond to eachline item. The supplier verifies and returns the document (402). Whenthe document is received, the OCR system reviews the document (404) andperforms a number of tasks (406).

As described above, the OCR system tags where the respective follow-upinformation is located for each line item within the document (408).Additionally, the system creates a horizontal or vertical snippet forthe information and associates it to the line item within the database(410). As mentioned above, the system also collects a signature at thebottom of the page. A separate snippet is created for the signature andoffered as part of the backup for any line item

With the creation of the follow-up snippet, signature snippet, and thesnippet from the original document it is possible to deliver line iteminformation within a GUI, complete with images from any and all relateddocuments (412). The system also provides links back to the area andpage on the originating document.

FIG. 5 is a flow diagram showing delivery of data from the database(500) with the corresponding snippets and links to one or more reportinginterfaces (502/504).

FIG. 6 is a screen display showing an example of a report. In this case,in addition to the report data itself 60, some details are displayedfrom the originating document 62, combined with follow-up data 64 and asignature 66, as snippet images from the respective original documents.

Computer Implementation

FIG. 7 is a block schematic diagram of a machine in the exemplary formof a computer system 1600 within which a set of instructions for causingthe machine to perform any one of the foregoing embodiment of theinvention may be executed. In alternative embodiments, the machine maycomprise or include a network router, a network switch, a networkbridge, personal digital assistant (PDA), a cellular telephone, a Webappliance or any machine capable of executing or transmitting a sequenceof instructions that specify actions to be taken.

The computer system 1600 includes a processor 1602, a main memory 1604and a static memory 1606, which communicate with each other via a bus1608. The computer system 1600 may further include a display unit 1610,for example, a liquid crystal display (LCD) or a cathode ray tube (CRT).The computer system 1600 also includes an alphanumeric input device1612, for example, a keyboard; a cursor control device 1614, forexample, a mouse; a disk drive unit 1616, a signal generation device1618, for example, a speaker, and a network interface device 1628.

The disk drive unit 1616 includes a machine-readable medium 1624 onwhich is stored a set of executable instructions, i.e., software, 1626embodying any one, or all, of the methodologies described herein below.The software 1626 is also shown to reside, completely or at leastpartially, within the main memory 1604 and/or within the processor 1602.The software 1626 may further be transmitted or received over a network1630 by means of a network interface device 1628.

In contrast to the system 1600 discussed above, a different embodimentuses logic circuitry instead of computer-executed instructions toimplement processing entities. Depending upon the particularrequirements of the application in the areas of speed, expense, toolingcosts, and the like, this logic may be implemented by constructing anapplication-specific integrated circuit (ASIC) having thousands of tinyintegrated transistors. Such an ASIC may be implemented withcomplementary metal oxide semiconductor (CMOS), transistor-transistorlogic (TTL), very large systems integration (VLSI), or another suitableconstruction. Other alternatives include a digital signal processingchip (DSP), discrete circuitry (such as resistors, capacitors, diodes,inductors, and transistors), field programmable gate array (FPGA),programmable logic array (PLA), programmable logic device (PLD), and thelike.

It is to be understood that embodiments may be used as or to supportsoftware programs or software modules executed upon some form ofprocessing core (such as the CPU of a computer) or otherwise implementedor realized upon or within a machine or computer readable medium. Amachine-readable medium includes any mechanism for storing ortransmitting information in a form readable by a machine, e.g., acomputer. For example, a machine readable medium includes read-onlymemory (ROM); random access memory (RAM); magnetic disk storage media;optical storage media; flash memory devices; electrical, optical,acoustical or other form of propagated signals, for example, carrierwaves, infrared signals, digital signals, etc.; or any other type ofmedia suitable for storing or transmitting information.

Although the invention is described herein with reference to thepreferred embodiment, one skilled in the art will readily appreciatethat other applications may be substituted for those set forth hereinwithout departing from the spirit and scope of the present invention.For example, while fax technology is discussed in connection with thepreferred embodiment of the invention, those skilled in the art willappreciate that the invention is applicable to a document provided inany input medium including, but not limited to, paper documents, emailmessages, database records, voice, video, and image data, andinformation-bearing signals, as well as, without limitation, documentsuploaded by a user (client, supplier, etc.). A further embodimentsupports Clients AP departments want to take AR ledgers that arereceived from suppliers in fax format and have them delivered to theclients in, for example, an Excel format. In this embodiment, a providerreceives AR ledger information from suppliers, converts them intodatabase formats, and submits the converted data back to the clients.Accordingly, the invention should only be limited by the Claims includedbelow.

1. An apparatus, comprising: a computer implemented system formanagement of accounts payable auditing data; and an OCR system, incommunication with said system for management of accounts payable and/oraccounts receivable auditing data, said OCR system configured to receivea document comprising a plurality of different tags in a first portionthereof; wherein said OCR system identifies a plurality of said tags andcompares said identified tags to supplier data stored in a database tovalidate said document.
 2. The apparatus of claim 1, wherein if the OCRsystem cannot validate the document, the document is routed to a GUI formanual sorting.
 3. The apparatus of claim 1, wherein said document firstportion comprises a document cover sheet, and wherein said OCR systemrecognizes at least the identity of a supplier and the identity of aclient to which the document should be routed.
 4. The apparatus of claim3, wherein said OCR system is configured to locate keywords on thedocument and caller ID information to suggest a correct supplier ifthere is no document coversheet.
 5. The apparatus of claim 1, whereinsaid OCR system is configured to clip a portion of the document thatcorresponds to a line item and to place said clipped portion in adatabase.
 6. The apparatus of claim 5, wherein said OCR system isconfigured to collect and associate all corresponding clipped portionswith their originating line items.
 7. The apparatus of claim 1, whereinsaid OCR system is configured to find an area of said document wheresaid supplier has entered contact information.
 8. The apparatus of claim7, wherein said OCR system is configured to recognize handwrittencontact information and to compares said handwritten contact informationto contact information for said supplier stored in a database; whereinif there is currently no data in the database, then the OCR systementers said recognized handwritten contact information and forwards saidrecognized handwritten contact information to a user in a GUI to verifysaid OCR system accuracy; wherein if there currently is data in thedatabase, then the OCR system compares it with said recognizedhandwritten contact information from the document and determines ifthere is a match; wherein if it is determined that there is a match,then the OCR system notes metadata accordingly; and wherein if it isdetermined that there is not a match, then the recognized handwrittencontact information from the document and the data in the database areboth sent to a GUI for human verification.
 9. The apparatus of claim 1,wherein said OCR system is configured to identify any tables in saiddocument, automatically read column headers in said tables, and comparesaid column headers to headers in a table master.
 10. the apparatus ofclaim 9, wherein said OCR system is configured to scan through anentirety of said document, place all targeted line items into saiddatabase, and mark said line items on a document within a GUI; whereinsaid OCR system is configured to tag a location of each targeted lineback to its original location in said document.
 11. The apparatus ofclaim 10, wherein said line items are sent to said GUI, supported bylink to an originating document and links to a corresponding clippedportion of said document.
 12. The apparatus of claim 1, wherein said OCRsystem is configured to automatically generate a verification request.13. The apparatus of claim 1, wherein said computer implemented systemfor management of accounts payable and/or accounts receivable auditingdata comprises a module for: managing accounts payable and/or accountreceivable data of a client, the accounts payable and/or accountreceivable data including at least one line item.
 14. The apparatus ofclaim 13, further comprising modules for: displaying an aged line itemfrom among the at least one line item, wherein the at least one lineitem relates to a request from a vendor for payment on an account forthe client; identifying credit data among the at least one displayedaged line item, wherein the credit data relates to a deduction that theclient can take against the requested payment; and recording theidentified credit data, wherein one or more of the managing, displaying,identifying and recording steps are implemented by the computer.
 15. Anapparatus, comprising: a computer implemented system for management ofaccounts payable and/or accounts receivable auditing data comprising amodule for managing accounts payable and/or account receivable data of aclient, the accounts payable and/or account receivable data including atleast one line item; and an OCR system, in communication with saidsystem for management of accounts payable and/or accounts receivableauditing data, said OCR system configured to receive a documentcomprising a plurality of different tags in a first portion thereof;wherein said OCR system identifies a plurality of said tags and comparessaid identified tags to supplier data stored in a database to validatesaid document.
 16. The apparatus of claim 15, further comprising modulesfor: displaying an aged line item from among the at least one line item,wherein the at least one line item relates to a request from a vendorfor payment on an account for the client; identifying credit data amongthe at least one displayed aged line item, wherein the credit datarelates to a deduction that the client can take against the requestedpayment; and recording the identified credit data, wherein one or moreof the managing, displaying, identifying and recording steps areimplemented by the computer;
 17. An apparatus, comprising: an OCRsystem, in communication with a system for management of accountspayable and/or accounts receivable auditing data, said OCR systemconfigured to receive a document comprising a plurality of differenttags in a first portion thereof; wherein said OCR system identifies aplurality of said tags and compares said identified tags to supplierdata stored in a database to validate said document; and wherein saidOCR system is configured to clip a portion of the document thatcorresponds to a line item and to place said clipped portion in adatabase.
 18. The apparatus of claim 17, wherein said OCR system isconfigured to collect and associate all corresponding clipped portionswith their originating line items.
 19. An apparatus, comprising: an OCRsystem, in communication with a system for management of accountspayable auditing data, said OCR system configured to receive a document;and wherein said OCR system is configured to clip a portion of thedocument that corresponds to a line item and to place said clippedportion in a database.
 20. A computer implemented method, comprising thesteps of: providing an OCR system, in communication with a system formanagement of accounts payable and/or accounts receivable auditing data,said OCR system configured to receive a document comprising a pluralityof different tags in a first portion thereof; said OCR systemidentifying a plurality of said tags and comparing said identified tagsto supplier data stored in a database to validate said document; andsaid OCR system clipping a portion of the document that corresponds to aline item and placing said clipped portion in a database.
 21. Anon-transitory computer readable storage medium having stored thereonprogram instructions which, when executed by a processor, implement themethod of claim 20.